Behavior Processors: Layers between End-Users and Java Virtual Machines

Visual programming approaches are limited in their usefulness if they do not include a profile of their users that defines exactly who is attempting to solve what kind of problems using which tools and why. Without such a definition, visual programming approaches can end up as solutions in search of problems. Reconceptualizing — programming environments as layered behavior processors in the context of creating SimCityTM-like interactive simulations — makes end-user programming more feasible. The layered approach serves the programming needs for a range of users, including casual computer end-users and professional programmers. The extension of the Agentsheets system with the RistrettoTM agent to Java bytecode compiler is used to illustrate how a behavior processor enables end-users to create their own Java applets that can be embedded into web pages. Copyright 1997 IEEE. Published in the Proceedings of VL'97, September 23-26, 1997 in Capri, Italy. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works, must be obtained from the IEEE. Contact: Manager, Copyrights and Permissions / IEEE Service Center / 445 Hoes Lane / P.O. Box 1331 / Piscataway, NJ 08855-1331, USA. Telephone: + Intl. 908-562-3966. Behavior Processors: Layers between End-Users and Java Virtual Machines Alexander Repenning and Andri Ioannidou Department of Computer Science Center for LifeLong Learning and Design University of Colorado, Boulder CO 80309-0430 (303) 492-1349, {ralex, andri}@cs.colorado.edu Fax: (303) 492-2844 http://www.cs.colorado.edu/~ralex/ Abstract partly due to the lack of specific statements about who is trying to solve what problems and how, as well as the lack of empirical studies that evaluate the performance of users solving problems. Visual programming approaches are limited in their usefulness if they do not include a profile of their users that defines exactly who is attempting to solve what kind of problems using which tools and why. Without such a definition, visual programming approaches can end up as solutions in search of problems. Reconceptualizing — programming environments as layered behavior processors in the context of creating SimCityTM-like interactive simulations — makes end-user programming more feasible. The layered approach serves the programming needs for a range of users, including casual computer end-users and professional programmers. The extension of the Agentsheets system with the RistrettoTM agent to Java bytecode compiler is used to illustrate how a behavior processor enables end-users to create their own Java applets that can be embedded into web pages. Knowledge of the mind sets, attitudes, and skills of endusers empowered by visual programming is important to understand the role of programming environments. For instance, most VCRs can be programmed, but VCRs are not considered programming environments, nor do most people using VCRs think of themselves as programmers enjoying the process of programming. For the majority of computer end-users the very notion of programming is daunting and, at the same time, completely secondary to the solution of a problem, such as taping a specific TV program. It is exactly this kind of programmer, who does not want to program, for whom visual programming could potentially make the biggest difference. Currently there are 90 million users of PCs — machines that are programmable — but the question is why should they want to program and what hope would they have to be able to program? Many people argue that programming a VCR is already so difficult that programming a much more complex device, such as a computer, would be an even more intricate process for that they see little hope of achieving. The following discussion refers to these kind of "forced" programmers, but by no means implies that visual programming should completely focus on them. In the past, some visual programming environments such as LabView [8] and Prograph [6] have successfully supported skilled programmers. Who is the programmer?partly due to the lack of specific statements about who is trying to solve what problems and how, as well as the lack of empirical studies that evaluate the performance of users solving problems. Visual programming approaches are limited in their usefulness if they do not include a profile of their users that defines exactly who is attempting to solve what kind of problems using which tools and why. Without such a definition, visual programming approaches can end up as solutions in search of problems. Reconceptualizing — programming environments as layered behavior processors in the context of creating SimCityTM-like interactive simulations — makes end-user programming more feasible. The layered approach serves the programming needs for a range of users, including casual computer end-users and professional programmers. The extension of the Agentsheets system with the RistrettoTM agent to Java bytecode compiler is used to illustrate how a behavior processor enables end-users to create their own Java applets that can be embedded into web pages. Knowledge of the mind sets, attitudes, and skills of endusers empowered by visual programming is important to understand the role of programming environments. For instance, most VCRs can be programmed, but VCRs are not considered programming environments, nor do most people using VCRs think of themselves as programmers enjoying the process of programming. For the majority of computer end-users the very notion of programming is daunting and, at the same time, completely secondary to the solution of a problem, such as taping a specific TV program. It is exactly this kind of programmer, who does not want to program, for whom visual programming could potentially make the biggest difference. Currently there are 90 million users of PCs — machines that are programmable — but the question is why should they want to program and what hope would they have to be able to program? Many people argue that programming a VCR is already so difficult that programming a much more complex device, such as a computer, would be an even more intricate process for that they see little hope of achieving. The following discussion refers to these kind of "forced" programmers, but by no means implies that visual programming should completely focus on them. In the past, some visual programming environments such as LabView [8] and Prograph [6] have successfully supported skilled programmers. Who is the programmer? With the next millennium in sight, the visual languages community is starting to take inventory of its successes and failures in order to develop new directions in which research can explore new ideas to increase the effectiveness of visual programming approaches. Several classification schemes [10, 18] have been proposed to structure a complex space populated with a variety of programming approaches. A nice and increasing set of cognitive dimensions [7] has not only been proposed but has also been used to evaluate and contrast both existing and hypothetical programming systems. Taxonomies and cognitive dimensions are important instruments of analysis, but they provide little information about the actual users of visual programming environments. Specifically, it is important to understand the backgrounds of users, their motivations, and their needs, and to get at least a sense of the problems they want to solve using visual programming environments. Visual language "superlativism" — that is, the bias toward overly optimistic and general assertions about the positive value of visual programming, excellently surveyed by Blackwell [2] — is As a programmable machine, the computer holds enormous potential as the ultimate flexible medium — a kind of computational clay — for people to express themselves or to communicate information to other people in new ways. The idea of using or even creating a computer as a simulation or game environment is appealing to many people [21], but, unfortunately, the current programming approaches — visual or not — place the ability create these things out of reach for the majority of people. We believe that in order to make the computer a more malleable medium in the next millennium it is necessary to get a much better sense of exactly who these people that we are trying to empower with visual (or other kinds of) programming really are. We may have to reconceptualize the very process of programming and its role in society. While cognitive dimensions and programming approach taxonomies are necessary instruments, we may have to increasingly draw from other fields of study such as anthropology, ethnography, and sociology. These users are not likely to employ elaborate analytical top-down planning processes to create working programs. These circumstances leave user manuals unread, resulting in "let's see what happens if I press this button" approaches. For typical Agentsheets users, the same situation holds true. That is, their main interest is to get a simulation running and not to write an elegantly generalizable program. Could this be a taste of what is to come for the next generation of end-user programmers? Turkle maintains that in the 1990s, as computing shifts away from a culture of calculation, bricolage has been given more room to flourish [21]. The emerging question is how a programming environment can accommodate bricolage. This paper can be little more than a small step toward this kind of goal. However, by drawing from experiences with a diverse group of users ranging from middle-school children creating educational simulations of the world (in which they live) to environmental design professionals simulating issues of sustainability in city planning, we hope to start a process of reconceptualization. Specifically, this paper outlines the notion of bricolage as a way to think about programmers and programming, and uses the Agentsheets system [15-17] to illustrate how bricolage can be supported with a so-called behavior processor. A first step toward creating a bricolage environment is to reconceptualize programming as a more domain-oriented process [5] that is more closely related to the actual problems to be solved. It is crucial to rethink the process of problem solving in this specific context and not just to find a substitute for the stigmatized programming word. In the context of creating simulations, we propose the term behavior processing, referring to the process of creating and using behavior units called agents. Analogous to a word processor, a behavior processor aids users in their process of dealing with behaviors. Word processors define a number of operations on words such as typing, spell checking, formatting, rearranging, and copying. Similarly, behavior processors define operations on behaviors as the basic units. Such operations include, but are not limited to, defining, modifying, merging, and exchanging behaviors. At the moment, these operations elevate behavior processing only slightly over traditional programming. From today's perspective WYSIWYG word processors seem to be obvious, but it took many years to develop the concept of a word processor. Bricolage The understanding of the intricate relationships among people, tools, and problems should not be limited to cognitive and technical issues, but should include what Papert calls intellectual style [12]. Papert and Turkle use the term "bricolage" to describe intellectual style in an educational context in which children program in Logo. The term bricolage was originally introduced by the French anthropologist Claude Lévi-Strauss to describe the process of theoretical tinkering by which individuals and cultures use objects around them to assimilate ideas. Papert defines bricolage as an organizational style that can be described as negotiational rather than planned in advance. Bricoleurs are "tinkers using what they got, improvise, and make do." Behavior Processors The role of a behavior processor is to support bricoleurs in creating, modifying, combining, and sharing behaviors. The Agentsheets system [15-17] is a behavior processor supporting a wide range of users to create SimCityTM-like interactive simulations. These simulations can be compiled down into Java applets that can be embedded directly into web pages. An agentsheet is an agent-based spreadsheet typically containing a large number of agents interacting with each other in ways similar to the interactions between cells in a spreadsheet. Each agent consists of behavior and look. Figure 1 below shows an Agentsheets application called "Der Packmann," which features a number of agent types, such as pacmans, monsters, pills, and walls. Bricolage, the process of gradually using components and building them up to larger and larger structures, is often found in environments such as spreadsheets. From a software engineering point of view, large spreadsheets maybe be declared to be hopeless disasters because they have organically grown bottom-up into increasingly complex webs of formulas to a point where the creator is the only person able to maintain them. While this approach does lead to a number of problems [22], it generally gets the job done for millions of spreadsheet users. The point here is not to judge bricolage as good or bad with respect to programming style, but to acknowledge that most people for whom programming is only a means to an end (e.g., the VCR or spreadsheet programmer), will resort to some kind of bricolage. This may be due to the lack of formal software engineering training but can also simply be the result of having other, more important things to do. In order to be effective for a wide range of applications, a behavior processor must be: • usable: allowing the bricoleur to solve simple problems in a simple way. For instance, to do frequent operations, such as moving an agent, the behavior processor must offer a recognizable solution. The behavior processor should not require the bricoleur to assemble fundamental operations first from lower-level operations. • expressive: with some additional effort it should still be possible to solve nontrivial and difficult-to-predict problems. These two characteristics represent a trade-off [15]. Programming approaches such as C++ are highly expressive, but are geared toward professional programmers. End-user programming approaches such as graphical rewrite rules [14, 20] are highly usable but are very limited in their ability to deal with more complex applications. Figure 1: Agentsheet containing pacmans, monsters, pills, and wall agents To illustrate the operation of a behavior processor, we use an analogy to word processors. Both word processors and behavior processors bridge a wide gap between human cognition and technology. The word processor supports the high-level (typically WYSIWYG) direct manipulation of words in order to create a document. The word processor can render an electronic version of a document into a more tangible form using a document description language such as Postscript. A Postscript file can be sent to a printer containing a Postscript interpreter which renders the description language into printed pieces of paper. Analogously, the behavior processor supports the direct manipulation of behaviors in order to create an interactive simulation or a game. The simulation, such as the pacman application of Figure 1, can be run in Agentsheets directly; that is, a user can plan the Pacman game or the behavior processor can render it into an applet consisting of Java byte codes. The applet, in turn, can be run on any hardware/software platform featuring a Java virtual machine [9]. In this sense it can be claimed that Java plays a role to networking very similar to the role Postscript plays to printing. Instead of striving for a single point — the Holy Grail — in the usability versus expressiveness space, the position taken here is that behavior processors need to be structured as layers providing end-users some choices in the usability versus expressiveness space. Expressiveness Graphical Rewrite Rules Tactile Programming Spreadsheet Formulas